Searched hist:df956ae2 (Results 1 – 5 of 5) sorted by relevance
/qemu/include/block/ |
H A D | blockjob.h | df956ae2 Wed Apr 25 13:09:58 GMT 2018 Kevin Wolf <kwolf@redhat.com> job: Add job_is_ready()
Instead of having a 'bool ready' in BlockJob, add a function that derives its value from the job status.
At the same time, this fixes the behaviour to match what the QAPI documentation promises for query-block-job: 'true if the job may be completed'. When the ready flag was introduced in commit ef6dbf1e46e, the flag never had to be reset to match the description because after being ready, the jobs would immediately complete and disappear.
Job transactions and manual job finalisation were introduced only later. With these changes, jobs may stay around even after having completed (and they are not ready to be completed a second time), however their patches forgot to reset the ready flag.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
|
/qemu/include/qemu/ |
H A D | job.h | df956ae2 Wed Apr 25 13:09:58 GMT 2018 Kevin Wolf <kwolf@redhat.com> job: Add job_is_ready()
Instead of having a 'bool ready' in BlockJob, add a function that derives its value from the job status.
At the same time, this fixes the behaviour to match what the QAPI documentation promises for query-block-job: 'true if the job may be completed'. When the ready flag was introduced in commit ef6dbf1e46e, the flag never had to be reset to match the description because after being ready, the jobs would immediately complete and disappear.
Job transactions and manual job finalisation were introduced only later. With these changes, jobs may stay around even after having completed (and they are not ready to be completed a second time), however their patches forgot to reset the ready flag.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
|
/qemu/ |
H A D | job.c | df956ae2 Wed Apr 25 13:09:58 GMT 2018 Kevin Wolf <kwolf@redhat.com> job: Add job_is_ready()
Instead of having a 'bool ready' in BlockJob, add a function that derives its value from the job status.
At the same time, this fixes the behaviour to match what the QAPI documentation promises for query-block-job: 'true if the job may be completed'. When the ready flag was introduced in commit ef6dbf1e46e, the flag never had to be reset to match the description because after being ready, the jobs would immediately complete and disappear.
Job transactions and manual job finalisation were introduced only later. With these changes, jobs may stay around even after having completed (and they are not ready to be completed a second time), however their patches forgot to reset the ready flag.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
|
H A D | blockjob.c | df956ae2 Wed Apr 25 13:09:58 GMT 2018 Kevin Wolf <kwolf@redhat.com> job: Add job_is_ready()
Instead of having a 'bool ready' in BlockJob, add a function that derives its value from the job status.
At the same time, this fixes the behaviour to match what the QAPI documentation promises for query-block-job: 'true if the job may be completed'. When the ready flag was introduced in commit ef6dbf1e46e, the flag never had to be reset to match the description because after being ready, the jobs would immediately complete and disappear.
Job transactions and manual job finalisation were introduced only later. With these changes, jobs may stay around even after having completed (and they are not ready to be completed a second time), however their patches forgot to reset the ready flag.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
|
H A D | qemu-img.c | df956ae2 Wed Apr 25 13:09:58 GMT 2018 Kevin Wolf <kwolf@redhat.com> job: Add job_is_ready()
Instead of having a 'bool ready' in BlockJob, add a function that derives its value from the job status.
At the same time, this fixes the behaviour to match what the QAPI documentation promises for query-block-job: 'true if the job may be completed'. When the ready flag was introduced in commit ef6dbf1e46e, the flag never had to be reset to match the description because after being ready, the jobs would immediately complete and disappear.
Job transactions and manual job finalisation were introduced only later. With these changes, jobs may stay around even after having completed (and they are not ready to be completed a second time), however their patches forgot to reset the ready flag.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
|